This error is visible to the user in its bare form, so I would rather keep the "Error" prefix.
Otherwise the user would just see this message:

$ flyscrape dev script.js
parsing config flags: <actual error message here>

How about this?

return fmt.Errorf("config: error parsing flags: %w", err)

or

return fmt.Errorf("error parsing config flags: %w", err)

We could make a small improvement by aligning it with the naming scheme from here, as those would also be user visible:
https://github.com/philippta/flyscrape/blob/master/flyscrape.go

as example of prefix:

// config: - configuration errors
// script: - script problems
// module: - errors in modules
// http: - network errors
// filesystem: - problems with the file system

While I like prefixes in general for logging or debugging (like in long running server applications), I wouldn’t put any of these kinds of prefixes on user visible errors. I don’t see many cli tools having prefixes in their error messages.

User visible errors should be as human readable and understandable as possible, like a regular English sentence.

I got it. So, then I suggest, fix only the small letter at the beginning.

LGTM